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Multiple Signatures in Cryptographic Message Syntax (CMS) 
Abstract 


Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo 
structure to convey per-signer information.  SignedData supports 
multiple signers and multiple signature algorithms per signer with 
multiple SignerInfo structures. If a signer attaches more than one 
SignerInfo, there are concerns that an attacker could perform a 
downgrade attack by removing the SignerInfo(s) with the ’strong’ 
algorithm(s). This document defines the multiple-signatures 
attribute, its generation rules, and its processing rules to allow 
Signers to convey multiple SignerInfo objects while protecting 
against downgrade attacks. Additionally, this attribute may assist 
during periods of algorithm migration. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5752. 
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Les 


1. 


Introduction 


The Cryptographic Message Syntax (CMS; see [CMS]) defined SignerInfo 
to provide data necessary for relying parties to verify the signer's 
digital signature, which is also included in the SignerInfo 
structure.  Signers include more than one SignerInfo in a SignedData 
if they use different digest or signature algorithms. Each 
SignerInfo exists independently and new SignerInfo structures can be 
added or existing ones removed without perturbing the remaining 
signatures. 


The concern is that if an attacker successfully attacked a hash or 
Signature algorithm, the attacker could remove all SignerInfo 
structures except the SignerInfo with the successfully attacked hash 
or signature algorithm. The relying party is then left with the 
attacked SignerInfo even though the relying party supported more than 
just the attacked hash or signature algorithm. 


A solution is to have signers include a pointer to all the signer's 
SignerInfo structures. If an attacker removes any SignerInfo, then 
relying parties will be aware that an attacker has removed one or 
more SignerInfo objects. 


Note that this attribute ought not be confused with the 
countersignature attribute (see Section 11.4 of [CMS]) as this is not 
intended to sign over an existing signature. Rather, it is to 
provide a pointer to additional signatures by the signer that are all 
at the same level. That is, countersignature provides a serial 
Signature while the attribute defined herein provides pointers to 
parallel signatures by the same signer. 


1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Rationale 


The rationale for this specification is to protect against downgrade 
attacks that remove the 'strong' signature to leave the 'weak' 
Signature, which has presumably been successfully attacked. If a CMS 
SignedData object has multiple SignerInfo objects, then the attacker, 
whether it be Alice, Bob, or Mallory, can remove a SignerInfo object 
without the relying party being aware that more than one was 
generated. 
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Removal of a SignerInfo does not render the signature invalid nor 
does it constitute an error. In the following scenario, a signer 
generates a SignedData with two SignerInfo objects, one with a 'weak' 
algorithm and one with a 'strong' algorithm; there are three types of 
relying parties: 


1) Those that support only a 'weak' algorithm. If both SignerInfo 
objects are present, the relying party processes the algorithm it 


supports. If both SignerInfo objects are not present, the relying 
party can easily determine that another SignerInfo has been 
removed, but not changed. In both cases, if the 'weak' signature 


verifies, the relying party MAY consider the signature valid. 


2) Those that support only a 'strong' algorithm. If both SignerInfo 
objects are present, the relying party processes the algorithm it 


supports. If both SignerInfo objects are not present, the relying 
party can easily determine that another SignerInfo has been 
removed, but the relying party doesn't care. In both cases, if 


the 'strong' signature verifies, the relying party MAY consider 
the signature valid. 


3) Those that support both a 'weak' algorithm and a ’strong’ 
algorithm. If both SignerInfo objects are present, the relying 
party processes both algorithms. If both SignerInfo objects are 
not present, the relying party can easily determine that another 
SignerInfo has been removed. In both cases, if the 'strong' 
and/or 'weak' signatures verify, the relying party MAY consider 
the signature valid. (Policy may dictate that both signatures are 
required to validate if present.) 


Local policy MAY dictate that the removal of the 'strong' algorithm 
results in an invalid signature. See Section 5 for further 
processing. 

2.1. Attribute Design Requirements 
The attribute will have the following characteristics: 
1) Use CMS attribute structure; 


2) Be computable before any signatures are applied; 


3) Contain enough information to identify individual signatures 
(i.e., a particular SignerInfo); and 


4) Contain enough information to resist collision, preimage, and 
second preimage attacks. 
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3. Multiple Signature Indication 


The multiple-signatures attribute type specifies a pointer toa 


signer’s other multiple-signatures attribute(s). For example, if a 
signer applies three signatures, there must be two attribute values 
for multiple-signatures in each SignerInfo. The 1st SignerInfo 


object points to the 2nd and 3rd SignerInfo objects. The 2nd 
SignerInfo object points to the lst and 3rd SignerInfo objects. The 
3rd SignerInfo object points to the lst and 2nd SignerInfo objects. 


The multiple-signatures attribute MUST be a signed attribute. The 
number of attribute values included in a SignerInfo is the number of 


Signatures applied by a signer less one. This attribute is multi- 
valued, and there MAY be more than one AttributeValue present. The 
following object identifier identifies the multiple-signatures 
attribute: 

id-aa-multipleSignatures OBJECT IDENTIFIER ::= { 


iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
id-aa(16) 51 } 


multiple-signatures attribute values have the ASN.1 type 


MultipleSignatures: 

MultipleSignatures ::= SEQUENCE { 
bodyHashAlg DigestAlgorithmIdentifier, 
signAlg SignatureAlgorithmIdentifier, 
signAttrsHash SignAttrsHash, 
cert ESSCertIDv2 OPTIONAL) 

SignAttrsHash ::- SEQUENCE { 
algID DigestAlgorithmIdentifier, 
hash OCTET STRING } 


The fields in MultipleSignatures have the following meaning: 


- bodyHashAlg includes the digest algorithmIdentifier for the 
referenced multiple-signatures attribute. 


- signAlg includes the signature algorithmIdentifier for the 
referenced multiple-signatures attribute. 


- signAttrsHash has two fields: 


-- algId MUST match the digest algorithm for the SignerInfo in 
which this multiple-signatures attribute value is placed. 


-- hash is the hash value of the signedAttrs (see Section 4.3). 
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- cert is optional. It identities the certificate used to sign the 
SignerInfo that contains the other multiple-signatures 
attribute(s). It MUST be present if the fields in the other 
multiple-signatures attribute(s) are the same. 


The following is an example: 


SignedData 
DigestAlg-shal,sha256 
SignerInfol SignerInfo2 
digestAlg-shal digestAlg-sha256 
signatureAlg-dsawithshal signatureAlg-ecdsawithsha256 
signedAttrs- signedAttrs- 
signingTimel signingTimel 
messageDigesti messageDigest2 
multiSigl= multiSig2= 
bodyHash=sha256 bodyHash=shal 
signAlg=ecdsawithsha256 signAlg=dsawithshal 
signAttrsHash= signAttrsHash= 
algID-shal algID-sha256 
hash-valuel hash-value2 


4. Message Generation and Processing 


The following are the additional procedures for message generation 
when using the multiple-signatures attribute. These paragraphs track 
with Sections 5.1-5.6 in [CMS]. 


4.1. SignedData Type 


The following steps MUST be followed by a signer when generating 
SignedData: 


- The signer MUST indicate the CMS version. 


- The signer SHOULD include the digest algorithm used in 
SignedData.digestAlgorithms, if the digest algorithm's identifier 
is not already present. 


- The signer MUST include the encapContentInfo. Note that the 
encapContentInfo is the same for all signers in this SignedData. 


- The signer SHOULD add certificates sufficient to contain 
certificate paths from a recognized "root" or "top-level 
certification authority" to the signer, if the signer's 
certificates are not already present. 
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- The signer MAY include the Certificate Revocation Lists (CRLs) 
necessary to validate the digital signature, if the CRLs are not 
already present. 

- The signer MUST: 


-- Retain the existing signerInfo objects. 


-- Include their signerInfo object(s). 


4.2.  EncapsulatedContentInfo Type 


The procedures for generating EncapsulatedContentInfo are as 
Specified in Section 5.2 of [CMS]. 


4.3. SignerInfo Type 


The procedures for generating SignerInfo are as specified in Section 
4.4.1 of [CMS] with the following addition: 


The signer MUST include the multiple-signatures attribute in 
signedAttrs. 


4.4. Message Digest Calculation Process 
4.4.1. multiple-signatures Signed Attribute Generation 


The procedure for generating the multiple-signatures signed attribute 
is as follows: 


1) All other signed attributes are placed in the respective 
SignerInfo structures, but the signatures are not yet computed for 
the SignerInfo. 

2) The multiple-signatures attributes are added to each of the 
SignerInfo structures with the SignAttrsHash.hash field containing 


a zero-length octet string. 


3) The correct SignAttrsHash.hash value is computed for each of the 
SignerInfo structures. 


4) After all hash values have been computed, the correct hash values 
are placed into their respective SignAttrsHash.hash fields. 


4.4.2. Message Digest Calculation Process 


The remaining procedures for generating the message-digest attribute 
are as specified in Section 5.4 of [CMS]. 
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4.5. Signature Generation Process 


The procedures for signature generation are as specified in Section 
5.5 of [CMS]. 


4.6. Signature Verification Process 


The procedures for signature verification are as specified in Section 
5.6 of [CMS] with the following addition: 


If the SignedData signerInfo includes the multiple-signatures 
attribute, the attribute’s values must be calculated as described in 
Section 4.4.1. 


For every SignerInfo to be considered present for a given signer, the 
number of MultipleSignatures AttributeValue(s) present in a given 
SignerInfo MUST equal the number of SignerInfo objects for that 
signer less one and the hash value present in each of the 
MultipleSignatures AttributeValue(s) MUST match the output of the 
message digest calculation from Section 4.4.1 for each SignerInfo. 


The hash corresponding to the n-th SignerInfo must match the value in 
the multiple-signatures attribute that points to the n-th SignerInfo 
present in all other SignerInfo objects. 


5. Signature Evaluation Processing 


This section describes recommended processing of signatures when 
there are more than one SignerInfo present in a message. This may be 
due to either multiple SignerInfo objects being present in a single 
SignedData object or multiple SignerData objects embedded in each 
other. 


The text in this section is non-normative. The processing described 
is highly recommended, but is not forced. Changes in the processing 
that have the same results with somewhat different orders of 
processing is sufficient. 

Order of operations: 


1) Evaluate each SignerInfo object independently. 


2) Combine the results of all SignerInfo objects at the same level 
(i.e., attached to the same SignerData object). 


3) Combine the results of the nested SignerData objects. Note that 


this should ignore the presence of other CMS objects between the 
SignedData objects. 
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5.1. Evaluation of a SignerInfo Object 


When evaluating a SignerInfo object, there are three different pieces 
that need to be examined. 


The first piece is the mathematics of the signature itself (i.e., can 
one actually successfully do the computations and get the correct 
answer?). This result is one of three results. The mathematics 
succeeds, the mathematics fails, or the mathematics cannot be 
evaluated. The type of things that lead to the last state are non- 
implementation of an algorithm or required inputs, such as the public 
key, are missing. 


The second piece is the validation of the source of the public key. 
For CMS, this is generally determined by extracting the public key 
from a certificate. The certificate needs to be evaluated. This is 
done by the procedures outlined in [PROFILE]. In addition to the 
processing described in that document, there may be additional 
requirements on certification path processing that are required by 
the application in question. One such set of additional processing 
is described in [SMIME-CERT]. One piece of information that is part 
of this additional certificate path processing is local and 
application policy. The output of this processing can actually be 
one of four different states: Success, Failure, Indeterminate, and 
Warning. The first three states are described in [PROFILE]; Warning 
would be generated when it is possible that some information is 
currently acceptable, but may not be acceptable either in the near 
future or under some circumstances. 


The third piece of the validation is local and application policy as 
applied to the contents of the SignerInfo object. This would cover 
such issues as the requirements on mandatory signed attributes or 
requirements on signature algorithms. 


5.2. Evaluation of a SignerInfo Set 
Combining the results of the individual SignerInfo objects into a 
result for a SignedData object requires knowledge of the results for 
the individual SignerInfo objects, the required application policy, 
and any local policies. The default processing if no other rules are 
applied should be: 
1) Group the SignerInfo objects by the signer. 


2) Take the best result from each signer. 


3) Take the worst result from all of the different signers; this is 
the result for the SignedData object. 
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Application and local policy can affect each of the steps outlined 
above. 


In Step 1: 


- If the subject name or subject alternative name(s) cannot be used 
to determine if two SignerInfo objects were created by the same 
identity, then applications need to specify how such matching is to 
be done. As an example, the S/MIME message specification [SMIME- 
MSG] could say that as long as the same rfc822Name exists in either 
the subject name or the subject alt name they are the same 
identity. This would be true even if other information that did 
not match existed in these fields. 


- Some applications may specify that this step should be skipped; 
this has the effect of making each SignerInfo object independent of 
all other SignerInfo objects even if the signing identity is the 
same. Applications that specify this need to be aware that 
algorithm rollover will not work correctly in this case. 


In Step 2: 


- The major policy implication at this step is the treatment of and 


order for the indeterminate states. In most cases, this state 
would be placed between the failure and warning states. Part of 
the issue is the question of having a multi-state or a binary 
answer as to success or failure of an evaluation. Not every 
application can deal with the statement "try again later". It may 
also be dependent on what the reason for the indeterminate state 
is. It makes more sense to try again later if the problem is that 


a CRL cannot be found than if you are not able to evaluate the 
algorithm for the signature. 


In Step 3: 
- The same policy implications from Step 2 apply here. 
5.3. Evaluation of a SignedData Set 
Simple applications will generally use the worst single outcome 
(success, unknown, failure) as the outcome for a set of SignedData 


objects (i.e., one failure means the entire item fails). However, 
not all applications will want to have this behavior. 
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7. 


des 


A work flow application could work as follows: 


The second signer will modify the original content, keep the original 
signature, and then sign the message. This means that only the 
outermost signature is of significance during evaluation. The second 
signer is asserting that they successfully validated the inner 
Signature as part of its processing. 


A Signed Mail application could work as follows: 


If signatures are added for the support of [ESS] features, then the 
fact that an outer layer signature cannot be validated can be treated 
as a non-significant failure. The only thing that matters is that 
the originator signature is valid. This means that all outer layer 
Signatures that fail can be stripped from the message prior to 
display leaving only the inner-most valid signature to be displayed. 


Security Considerations 


Security considerations from the hash and signature algorithms used 
to produce the SignerInfo apply. 


If the hashing and signing operations are performed by different 
entities, the entity creating the signature must ensure that the hash 
comes from a "trustworthy" source. This can be partially mitigated 
by requiring that multiple hashes using different algorithms are 
provided. 


This attribute cannot be relied upon in the event that all of the 

algorithms used in the signer attribute are 'cracked'. It is not 

possible for a verifier to determine that a collision could not be 
found that satisfies all of the algorithms. 


Local policy and applications greatly affect signature processing. 
The application of local policy and the requirements specific to an 
application can both affect signature processing. This means that a 
Signature valid in one context or location can fail validation in a 
different context or location. 


References 
1. Normative References 
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 


5652, September 2009. 


Turner & Schaad Standards Track [Page 11] 


RFC 5752 


[PROFILE] 


[SMIME-CERT ] 


[SMIME-MSG] 


[ESS] 


[ESSCertID] 


Multiple Signatures in S/MIME January 2010 


Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 
Housley, R., and W. Polk, "Internet X.509 Public Key 
Infrastructure Certificate and Certificate Revocation 
List (CRL) Profile", RFC 5280, May 2008. 


Ramsdell, B. and S. Turner, "Secure/Multipurpose 
Internet Mail Extensions (S/MIME) Version 3.2 
Certificate Handling", RFC 5750, January 2010. 


Ramsdell, B. and S. Turner, "Secure/Multipurpose 
Internet Mail Extensions (S/MIME) Version 3.2 Message 
Specification", RFC 5751, January 2010. 


Hoffman, P., Ed., "Enhanced Security Services for 
S/MIME", RFC 2634, June 1999. 


Schaad, J., “Enhanced Security Services (ESS) Update: 
Adding CertID Algorithm Agility", RFC 5035, August 
2007. 


7.2. Informative References 


[ATTACK] 


Turner & Schaad 


Hoffman, P. and B. Schneier, "Attacks on Cryptographic 
Hashes in Internet Protocols", RFC 4270, November 2005. 


Standards Track [Page 12] 


RFC 5752 Multiple Signatures in S/MIME January 2010 


Appendix A. ASN.1 Module 
MultipleSignatures-2008 
( iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs9(9) smime(16) modules(0) 
id-mod-multipleSig-2008 (34) } 
DEFINITIONS IMPLICIT TAGS ::- 
BEGIN 


-- EXPORTS All 


-- The types and values defined in this module are exported for use 
-- in the other ASN.1 modules. Other applications may use them for 
-- their own purposes. 


IMPORTS 
-- Imports from RFC 5652 [CMS], 12.1 
DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier 
FROM CryptographicMessageSyntax2004 
( iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs9(9) smime(16) modules(0) cms-2004(24) } 
-- Imports from RFC 5035 [ESSCertID], Appendix A 


ESSCertIDv2 
FROM ExtendedSecurityServices-2006 
( iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-ess-2006(30) } 


; 
-- Section 3.0 


id-aa-multipleSignatures OBJECT IDENTIFIER ::= ( iso(1) member-body (2) 
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 } 


MultipleSignatures ::= SEQUENCE { 
bodyHashAlg DigestAlgorithmIdentifier, 
signAlg SignatureAlgorithmIdentifier, 
signAttrsHash SignAttrsHash, 
cert ESSCertIDv2 OPTIONAL ] 
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SignAttrsHash ::= SEQUENCE { 
algID DigestAlgorithmIdentifier, 
hash OCTET STRING } 

END -- of MultipleSignatures-2008 
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Appendix B. Background 
This is an informational appendix. This appendix enumerates all 
locations in CMS where hashes are used and the possible attacks on 
those hash locations. 


B.1. Attacks 


As noted in [ATTACK], the following types of resistance are needed 
against known attacks: 


1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 

2) Preimage Resistance: Given y, find x where H(x) = y 

3) Second Preimage Resistance: Given y, find x where H(x) = H(y) 
Note: It is known that a collision resistance attack is simpler than 


a second preimage resistance attack, and it is presumed that a second 
preimage resistance attack is simpler than a preimage attack. 


B.2. Hashes in CMS 

Within a SignerInfo there are two places where hashes are applied and 

hence can be attacked: the body and the signed attributes. The 

following outlines the entity that creates the hash, the entity that 
attacks the hash, and the type of resistance required: 

1) Hash of the Body (i.e., the octets comprising the value of the 
encapContentInfo.eContent OCTET STRING omitting the tag and length 
octets, as per 5.4 of [CMS]). 

a) If Alice creates the body to be hashed, then: 


i) Alice can attack the hash. This attack requires a 
successful collision resistance attack. 


ii) Mallory can attack the hash. This attack requires a 
successful second preimage resistance attack. 


b) If Alice hashes a body provided by Bob, then: 


i) Alice can attack the hash. This attack requires a 
successful second preimage attack. 
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2) 


ii) Bob can attack the hash. This attack requires a successful 
Collision Resistance attack. If Alice has the ability to 
"Change" the content of the body in some fashion, then this 
attack requires a successful second preimage attack. (One 
example would be to use a keyed hash function.) 


iii) Mallory can attack the hash. This attack requires a 
successful second preimage attack. 


c) If Alice signs using a hash value provided by Bob (in this 
case, Alice is presumed to never see the body in question), 
then: 


i) Alice can attack the hash. This attack requires a 
successful preimage attack. 


ii) Bob can attack the hash. This attack requires a successful 
collision resistance attack. Unlike case (b), there is 
nothing that Alice can do to upgrade the attack. 


iii) Mallory can attack the hash. This requires a successful 
preimage attack if the content is unavailable to Mallory and 
a successful second preimage attack if the content is 
available to Mallory. 


Hash of signed attributes (i.e., the complete Distinguished 
Encoding Rules (DER) encoding of the SignedAttrs value contained 
in the signedAttrs field, as per 5.4 of [CMS]). 


There is a difference between hashing the body and hashing the 
SignedAttrs value in that one should not accept a sequence of 
attributes to be signed from a third party. In fact, one should 
not accept attributes to be included in the signed attributes list 
from a third party. The attributes are about the signature you 
are applying and not about the body. If there is meta-information 
that needs to be attached to the body by a third party, then they 
need to provide their own signature and you need to adda 
countersignature. (Note: The fact that the signature is to be 
used as a countersignature is a piece of information that should 
be accepted, but it does not directly provide an attribute that is 
inserted in the signed attribute list.) 


a) Alice can attack the hash. This requires a successful 
collision resistance attack. 


b) Mallory can attack the hash. This requires a successful second 
preimage resistance attack. 
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c) Bob can attack the hash and Bob controls the value of the 
message digest attribute used. This case is analogous to the 
current attacks [ATTACK]. Bob can attack the hash value 
generated by Alice based on a prediction of the signed 
attributes and the hash algorithm Alice will be using to create 
the signature. If Bob successfully predicts these items, the 
attack requires a successful collision resistance attack. (It 
is expected that if Alice uses a keyed hashing function as part 
of the signature, this attack will be more difficult as Bob 
would have a harder time prediction the key value.) 


It should be noted that both of these attacks are considered to be 

more difficult than the attack on the body since more structure is 

designed into the data to be hashed than is frequently found in the 
body and the data is shorter in length than that of the body. 


The successful prediction of the signing-time attribute is expected 
to be more difficult than with certificates as the time would not 
generally be rounded. Time stamp services can make this more 
unpredictable by using a random delay before issuing the signature. 


Allowing a third party to provide a hash value could potentially make 
an attack simpler when keyed hash functions are used since there is 
more data than can be modified without changing the overall structure 
of the signed attribute structure. 
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